home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-osids-chart-network-dir-00.txt < prev    next >
Text File  |  1993-09-02  |  28KB  |  923 lines
  1.  
  2.  
  3.  
  4.  
  5. OSI-DS Working Group                                    Glenn Mansfield
  6. INTERNET-DRAFT                                       (AIC Systems Lab.)
  7.                                                        Thomas Johannsen
  8.                                                    (Dresden University)
  9.                                                            Mark Knopper
  10.                                                        (Merit Networks)
  11.                                                          September 1993
  12.  
  13.  
  14.  
  15.  
  16.                    Charting Networks in the Directory
  17.  
  18.  
  19.                       Draft document OSI-DS-37-01
  20.  
  21.  
  22. Status of this Memo
  23.  
  24.    This document is an  Internet  Draft.  Internet  Drafts  are  working
  25.    documents  of  the Internet Engineering Task Force (IETF), its Areas,
  26.    and its Working Groups. Note that other groups  may  also  distribute
  27.    working documents as Internet Drafts.
  28.  
  29.    Internet Drafts are draft  documents  valid  for  a  maximum  of  six
  30.    months.  Internet  Drafts  may  be updated, replaced, or obsoleted by
  31.    other documents at any time.  It is not appropriate to  use  Internet
  32.    Drafts as reference material or to cite them other than as a "working
  33.    draft" or "work in progress."
  34.  
  35.    To learn the current status of any Internet-Draft, please  check  the
  36.    1id-abstracts.txt  listing  contained  in  the Internet-Drafts Shadow
  37.    Directories on ds.internic.net, nic.nordu.net,  ftp.nisc.sri.com,  or
  38.    munnari.oz.au.
  39.  
  40.  
  41. Abstract
  42.  
  43. There is a need for a framework wherein the infrastructural and  service
  44. related  information about communication networks can be made accessible
  45. from all places and at all times in a reasonably  efficient  manner  and
  46. with  reasonable  accuracy.   This  document presents a model in which a
  47. communication network with all its related details and descriptions  can
  48. be  represented  in  the  X.500  Directory. Schemas of objects and their
  49. attributes which may be used for this purpose are presented.  The  model
  50. envisages  physical  objects  and  several  logical  abstractions of the
  51. physical objects.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62. Expires: March 1, 1994                                        [Page 1]
  63.  
  64.  
  65.  
  66.  
  67.  
  68. Internet Draft                 OSI-DS 37                  September 1993
  69.  
  70.  
  71. Contents
  72.  
  73.  
  74.       1. Introduction                                     2
  75.       2. Infrastructural information requirements         2
  76.       3. The Nature of the Network Map                    4
  77.       4. The hierarchical model of a network              5
  78.       4.1 Network maps                                    5
  79.       4.2 Representation in the X.500 Directory           5
  80.       5. Position in The Directory Information Tree       7
  81.       6. Proposed Schemes                                 8
  82.       6.1 Communication Object Classes                    8
  83.       6.2 Physical elements                               9
  84.       6.2.1 Network                                       9
  85.       6.2.2 Node                                         10
  86.       6.2.3 NetworkInterface                             10
  87.       6.3 Logical Elements                               11
  88.       6.3.1 Network                                      11
  89.       6.3.2 Node                                         12
  90.       6.3.3 NetworkInterface                             12
  91.       7. Security Considerations                         13
  92.       8. Authors' Addresses                              13
  93.  
  94.  
  95. 1. Introduction
  96.  
  97. The rapid and widespread use of computer networking has highlighted  the
  98. importance  of  holding  and  servicing information about the networking
  99. infrastructure itself.  The  growing  and  active  interest  in  network
  100. management,  which  has  concentrated  mainly  in the areas of fault and
  101. performance management on a local scale, is severely constrained by  the
  102. lack   of   any   organized   pool  of  information  about  the  network
  103. infrastructure itself. Some attempts have  been  made,  on  a  piecemeal
  104. basis, to provide a larger view of some particular aspect of the network
  105. (WHOIS, DNS, .. in the case of the Internet;  [WHOIS],  [DNS]).  But  to
  106. date,   little   or   no   effort  has  been  made  in  setting  up  the
  107. infrastructural framework, for such an information pool. In this work we
  108. explore  the possibility of setting up a framework to hold and serve the
  109. infrastructural information of a network.
  110.  
  111.  
  112. 2. Infrastructural information requirements
  113.  
  114. Network  operation  and  management  requires  information   about   the
  115. structure  of  the  network,  the  nodes,  links  and  their properties.
  116. Further, with current networks extending literally  beyond  bounds,  the
  117. scope of the information covers networks beyond the span of local domain
  118. of authority or administration.   When the Network was relatively  small
  119. and  simple  the  map  was  already  known  to  the knowledgable network
  120. administrator.  Based on this knowledge the course  of  the  packets  to
  121. different  destinations  would be charted. But presently the size of the
  122. Network is already beyond such usages. The current growth of the Network
  123. is near explosive. This is giving rise to the urgent necessity of having
  124. infrastructural and service related information made accessible from all
  125.  
  126.  
  127.  
  128. Expires: March 1, 1994                                        [Page 2]
  129.  
  130.  
  131.  
  132.  
  133.  
  134. Internet Draft                 OSI-DS 37                  September 1993
  135.  
  136.  
  137. places  and  at  all  times  in  a  reasonably efficient manner and with
  138. reasonable accuracy. In the rest of this work a network is the media for
  139. transmitting  information.  Network  elements are equipment with  one or
  140. more network interfaces whereby it is possible to  exchange  information
  141. with  the  network.  Network  elements  with  multiple  interfaces  e.g.
  142. gateways/routers/bridges/repeaters...  may be used to connect  networks.
  143. Network related information, referred to as 'network map' in the rest of
  144. this paper, should
  145.  
  146. 1. Show the interconnection between the various network
  147.    elements. This will basically represent the Network as a graph
  148.    where vertices represent objects like gateways/workstations/
  149.    subnetworks and edges indicate the connections.
  150. 2. Show properties and functions of the various network elements
  151.    and the interconnections. Attributes of vertices will represent
  152.    various properties of the objects e.g. speed, charge, protocol, OS,
  153.    etc. Functions include services offered by a network element.
  154. 3. Contain various name and address information of the networks
  155.    and network elements
  156. 4. Contain information about various administrative and management
  157.    details related to the networks and network elements.
  158. 5. Contain the policy related information, part of which may be
  159.    private while the other part may be made public.
  160.  
  161. Using this map the following services may be provided
  162.  
  163. 1. Configuration management:
  164.   o Display the physical configuration of a network,
  165.     i.e. nodes and their physical interconnections
  166.   o Display the logical configuration of a network,
  167.     i.e. nodes and their logical interconnections.
  168. 2. Route management:
  169.   o Find alternate routes by referring to the physical
  170.     and logical configurations.
  171.   o Generate routing tables considering local policy and
  172.    policy of transit domains
  173.   o Check routing tables for routing loops,
  174.     non-optimality, incorrect paths, etc.
  175. 3. Fault management: In case of network failures
  176.    alternatives may be found and used to bypass the
  177.    problem node or link.
  178. 4. Service management: Locate various services and
  179.    servers in the Network.
  180. 5. Optimization: The information available can be used
  181.    to carry out various optimizations, for example cost,
  182.    traffic, response-time, etc.
  183. 6. Provide mappings between the various names and
  184.    addresses of elements
  185. 7. Depict administrative/autonomous domains.
  186. 8. Network Administration and Management: References to
  187.    people responsible for administering and technically
  188.    maintaining a network will be useful.
  189.  
  190. Examples of such usages are described in [IP], [SPP].
  191.  
  192.  
  193.  
  194. Expires: March 1, 1994                                        [Page 3]
  195.  
  196.  
  197.  
  198.  
  199.  
  200. Internet Draft                 OSI-DS 37                  September 1993
  201.  
  202.  
  203. 3. The Nature of the Network Map - The X.500 solution
  204.  
  205. Implementing and maintaining a detailed  map  of  the  network  poses  a
  206. serious  problem.  The scope of the map is global and the network itself
  207. is expanding.  Some of the problems that are peculiar to the network map
  208. are listed below-
  209.  
  210. o The Network configuration is quasi-static. Nodes,
  211.   links and networks are being added,updated and deleted
  212.   someplace or the other.
  213. o The Network is huge and geographically distributed.
  214. o The network spans several political and administrative
  215.   areas. The related information is also controlled and
  216.   maintained in a distributed fashion.
  217.  
  218. In short, global network  configuration  information  is  unwieldy   and
  219. growing continuously.  It is impossible to service such information in a
  220. centralized fashion. There is need for  a  distributed  framework  which
  221. allows  users   and  applications  to  access  information about  users,
  222. services, networks, ... easily and globally.  The  OSI  X.500  Directory
  223. services [X.500-88] provides a  rich  framework  to  support a  globally
  224. distributed   information   service   system.  The  X.500  Directory  is
  225. intended  to  be  a  very  large  and highly distributed database. It is
  226. structured hierarchically with entries arranged in the form of a tree in
  227. which  each  object  corresponds  to  a node or an entry. Information is
  228. stored about an object as a set of attributes.
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260. Expires: March 1, 1994                                        [Page 4]
  261.  
  262.  
  263.  
  264.  
  265.  
  266. Internet Draft                 OSI-DS 37                  September 1993
  267.  
  268.  
  269. 4. The hierarchical model of a network
  270.  
  271. For  representing  networks  in  the  Directory  we  use  the  following
  272. hierarchical model.
  273.  
  274. A network is the media for transmitting information with  zero  or  more
  275. network  elements  each  having  at  least  one network interface on the
  276. media. The media may be any kind of  a  line  (physical  circuit/virtual
  277. circuit), or a collection of interconnected networks.
  278.  
  279.  
  280.        <  The postscript version of this document  >
  281.        <  has a figure here. However, the figure   >
  282.        <is too complex to be drawn in simple ASCII.>
  283.  
  284.  Figure 1:  Simple and composite networks and their mapping to the DIT.
  285.  
  286. The  model  allows  hierarchy  of  subnetworks.  Network  elements  with
  287. multiple  interfaces  may  act  as  external  gateways   to the attached
  288. network and to networks higher up in the hierarchy.  Thus, a gateway may
  289. be   the   external   gateway  of  several  networks  which  are  either
  290. interconnected or have a hierarchical relationship.
  291.  
  292. A network may be simple  consisting of  zero or more network elements or
  293. composite   consisting  of  several  sub-networks.  Examples  of  simple
  294. networks are ethernets, optical fiber/copper cables, free space, ... .
  295.  
  296.  
  297. 4.1 Network Maps
  298.  
  299. Using the above model it is straight forward  to  draw  the  topological
  300. graph  of the network where the vertices represent the components of the
  301. network and edges indicate the connections.  For  visual  representation
  302. the  graph  may  be translated to a more "physical" illustration (figure
  303. 1).
  304.  
  305. Just  as  there  are  several  maps  of  the  same  geographical  domain
  306. (political,  natural...)  one  can  envisage  several  views of the same
  307. network and its components. A view (called ``image'' in  the  remainder)
  308. could   pertain   to   a  particular  protocol  suite  (IP/OSI/...),  an
  309. administrative domain or purpose.  Using images, several abstractions of
  310. the same object are possible.
  311.  
  312.  
  313. 4.2 Representation in the X.500 Directory
  314.  
  315. To represent the various images of networks  and  its  components  along
  316. with  the real-image relationship among the various objects we introduce
  317. the following classes of objects:
  318.  
  319. o Communication Object Class (CO): All objects defined
  320.   furtheron in this document belong to this class.
  321.   Common attributes for all communication objects are
  322.   defined in section 6.
  323.  
  324.  
  325.  
  326. Expires: March 1, 1994                                        [Page 5]
  327.  
  328.  
  329.  
  330.  
  331.  
  332. Internet Draft                 OSI-DS 37                  September 1993
  333.  
  334.  
  335. o Physical Communication Object Class (PCO): A subclass
  336.   of CO-class, this class defines common properties for
  337.   all objects representing physical communication objects.
  338. o Image Communication Object Class (ICO): A subclass of
  339.   CO-class, this class defines common properties for all
  340.   objects representing images of communication objects.
  341.  
  342. The above classes sort communication  objects  into  physical  or  image
  343. object.   As  is implied in the nomenclature a physical object will have
  344. several attributes describing it physical properties - location, weight,
  345. size,  ....  etc.  An  image object will have an Image-of attribute. The
  346. Image-of attribute will point to a physical object or to  another  image
  347. object.
  348.  
  349. Using this schema it is  possible  to  represent  the  case  of  several
  350. logical  network  systems  (running different protocol stacks - IP, XNS,
  351. SNA, OSI, ...) which coexist on the same physical  network.  Information
  352. related  to  different  types of networks, no matter what the underlying
  353. communication protocol is, will reside  in  the  Directory  in  harmony.
  354. Also,  their interrelation will be represented and accessed in a fashion
  355. independent of the source/destination network,  namely,  using  the  OSI
  356. X.500 protocol.
  357.  
  358. Schemes for physical networks and logical images  of  physical  networks
  359. are defined in section 6.
  360.  
  361.        <  The postscript version of this document  >
  362.        <  has a figure here. However, the figure   >
  363.        <is too complex to be drawn in simple ASCII.>
  364.  
  365.       Figure 2: Several logical views of the same physical network
  366.  
  367. All objects are defined in section 6.
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392. Expires: March 1, 1994                                        [Page 6]
  393.  
  394.  
  395.  
  396.  
  397.  
  398. Internet Draft                 OSI-DS 37                  September 1993
  399.  
  400.  
  401. 5. Position in the Directory Information Tree (DIT)
  402.  
  403. Information about networks usually will  be  contained  in  the  DIT  as
  404. subordinate  of  the  organization  maintaining the network. The network
  405. model gets mapped into a tree structure for network elements.  There  is
  406. one   network   object  giving  general  descriptions  of  the  network.
  407. Subordinates of this network object  are  node  objects  for  each  node
  408. element  present  in  the  network.  Node objects hold  networkInterface
  409. objects as subordinates.  A  network  can  be  physically  or  logically
  410. subdivided  into  several  (sub)networks.  In this case, a network entry
  411. will have network objects as subordinates which  again  build  the  same
  412. structure.    These   entries   may   be   kept   as   subordinates   of
  413. organizationalUnit entries  as  well,  with  pointers  from  the  "root"
  414. network.
  415.  
  416. This  structure  holds  for  physical  and  logical  elements.  Physical
  417. elements  are  named  network,  node  and  networkInterface, and logical
  418. elements are named networkImage, nodeImage and networkInterfaceImage.
  419.  
  420.        <  The postscript version of this document  >
  421.        <  has a figure here. However, the figure   >
  422.        <is too complex to be drawn in simple ASCII.>
  423.  
  424.            Figure 3: Part of the Directory Information Tree,
  425.           showing relations of White Pages and network objects
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458. Expires: March 1, 1994                                        [Page 7]
  459.  
  460.  
  461.  
  462.  
  463.  
  464. Internet Draft                 OSI-DS 37                  September 1993
  465.  
  466.  
  467. 6. Proposed Schemes
  468.  
  469. A physical network comprises of wires and machines. The physical map  of
  470. the  network  will  show  the  interconnections  of these nodes by these
  471. circuits.
  472.  
  473. For each physical  network  element,  one  or  more  images  may  exist.
  474. Similarly,  an  image  may  be attached to one or more physical objects.
  475. The types of images can grow along with the requirements.   Relationship
  476. between  elements  (physical  or logical) are expressed by attributes or
  477. the position in the Diretory tree.
  478.  
  479. Problems that are addressed in the schema:
  480.  
  481. 1. Avoiding data duplication
  482. 2. Preserving administrative boundaries/controls.
  483. 3. Simple representation (minimal number of pointers)
  484. 4. Security: Though no special emphasis has been placed
  485.    in this work we believe the X.500 access control
  486.    policies will provide reasonable privacy.
  487.  
  488. Problems that are not addressed:
  489.  
  490. 1. Caching policies, etc.: to be decided  locally
  491.  
  492.  
  493. 6.1 Communication Object Classes
  494.  
  495. The object classes introduced in section 4 are defined as
  496. follows:
  497.  
  498. CommunicationObject OBJECT CLASS
  499.  SUBCLASS of top
  500.  MAY CONTAIN {
  501.   description :: CaseIgnoreStringSyntax,
  502.    /* can contain any information about the object,
  503.       however, whereever an appropiate attribute
  504.       exists, this should be used first to hold
  505.       information */
  506.   adminContact :: distinguishedNameSyntax,
  507.    /* points to the person which is responsible for
  508.       the administration of the instance this object
  509.       describes;
  510.       This refers to the instance only in the context
  511.       of the concrete object class */
  512.   technContact :: distinguishedNameSyntax,
  513.    /* points to the person which is responsible for
  514.       the technical maintanence of the instance this
  515.       object describes;
  516.       This refers to the instance only in the context
  517.       of the concrete object class;
  518.       Availability (e.g. hours of service) is not
  519.       covered by this attribute. */
  520.  }
  521.  
  522.  
  523.  
  524. Expires: March 1, 1994                                        [Page 8]
  525.  
  526.  
  527.  
  528.  
  529.  
  530. Internet Draft                 OSI-DS 37                  September 1993
  531.  
  532.  
  533. PhysicalCommunicationObject OBJECT CLASS
  534.  SUBCLASS of CommunicationObject
  535.  MAY CONTAIN{
  536.   owner :: distinguishedNameSyntax,
  537.    /* refers to organization or person owning the
  538.      physical element;
  539.      Note that more detailed information (like lease,
  540.      rental, etc.) can be covered in a specific image
  541.      (ownerImage) of this element */
  542.   localityName :: CaseIgnoreStringSyntax
  543.    /* where the object is located;
  544.       can be used freely to "spot" a network element,
  545.       e.g. state/city/street/building/floor/room/
  546.       desk/... */
  547.   ICO :: distinguishedNameSyntax
  548.    /* points to image object the physical object
  549.       is related to;
  550.          might have several values if physical object
  551.          is use for several applications at the same time */
  552.         }
  553.  
  554. ImageCommunicationObject OBJECT CLASS
  555.  SUBCLASS of CommunicationObject
  556.  MAY CONTAIN{
  557.   type :: caseIgnoreStringSyntax,
  558.    /* expresses the view this object referes to, e.g.
  559.       view of provider/user/IP/OSI/...;
  560.          Note that this information can be covered by
  561.          the object class in some cases
  562.          (e.g. ipNetworkImage gives the IP view) */
  563.   imageOf :: distinguishedNameSyntax,
  564.    /* points to physical/image object the image
  565.       is related to;
  566.          might have several values if view applies to
  567.          several physical objects at the same time */
  568.  }
  569.  
  570.  
  571. 6.2 Physical elements
  572.  
  573. The following objects describe network elements without saying  anything
  574. about   their   usage.   All   objects   inherit   properties   of   the
  575. PhysicalCommunicationObject class.
  576.  
  577.  
  578. 6.2.1 Network
  579.  
  580. The network object supplies general descriptions which are common for  a
  581. set  of  nodes  and  circuits  comprising  one  network.  This  includes
  582. information about the type of circuits (medium, broadcast  or  point-to-
  583. point, etc.) and properties (speed etc.).
  584.  
  585. network OBJECT CLASS
  586.  SUBCLASS of PhysicalCommunicationObject
  587.  
  588.  
  589.  
  590. Expires: March 1, 1994                                        [Page 9]
  591.  
  592.  
  593.  
  594.  
  595.  
  596. Internet Draft                 OSI-DS 37                  September 1993
  597.  
  598.  
  599.  MUST CONTAIN  {
  600.   networkName :: caseIgnoreStringSyntax }
  601.  MAY CONTAIN {
  602.   externalGateway :: distinguishedNameSyntax,
  603.    /* points to one or more nodes that connect
  604.       this network to neighbor networks;
  605.          whether a node actually is used as gateway
  606.          for one or the other protocol, is defined
  607.          in a related networkImageObject */
  608.   nwType :: caseIgnoreStringSyntax,
  609.    /* type of this network;
  610.       either "composite" (if consisting of subnetworks)
  611.       or type of a line:
  612.       bus, ring, star, mesh, point-to-point */
  613.   media :: caseIgnoreStringSyntax,
  614.    /* if network is not composite,
  615.       describes physical media:
  616.       copper, fiber optic, etc. */
  617.   speed :: numericStringSyntax,
  618.    /* nominal bandwidth, e.g. 64 kbps */
  619.   traffic :: numericStringSyntax
  620.    /* (average) use in percent of nominal bandwidth
  621.          [ this needs more specification later ] */
  622.   configurationDate ::  uTCTimeSyntax,
  623.    /* date when network was configured in current
  624.          shape */
  625.   configurationHistory :: caseIgnoreStringSyntax
  626.    /* list of configuration changes, like:
  627.          added/removed nodes, lines */
  628.   }
  629.  
  630.  
  631. 6.2.2 Node
  632.  
  633. The node object describes any  kind  of  device  that  is  part  of  the
  634. network, such as simple nodes, printer, bridges.
  635.  
  636. node OBJECT CLASS
  637.  SUBCLASS of PhysicalCommunicationObject
  638.  MUST CONTAIN{
  639.   nodeName :: caseIgnoreStringSyntax }
  640.  MAY CONTAIN {
  641.   machineType :: caseIgnoreStringSyntax,
  642.    /* e.g. main frame, work station, PC, printer;
  643.       might include manufacturer */
  644.   OS :: caseIgnoreStringSyntax,
  645.    /* e.g. VM, UNIX, DOS; might include release */
  646.  }
  647.  
  648.  
  649. 6.2.3 NetworkInterface
  650.  
  651. Each node object will have  one  or  more  networkInterface  objects  as
  652. subordinates.    NetworkInterface   objects  provide  information  about
  653.  
  654.  
  655.  
  656. Expires: March 1, 1994                                       [Page 10]
  657.  
  658.  
  659.  
  660.  
  661.  
  662. Internet Draft                 OSI-DS 37                  September 1993
  663.  
  664.  
  665. interfaces of the node and connectivity.
  666.  
  667. networkInterface OBJECT CLASS
  668.  SUBCLASS of PhysicalCommunicationObject
  669.  MUST CONTAIN {
  670.   networkInterfaceName :: caseIgnoreStringSyntax }
  671.    /* It is suggested that the networkInterface name
  672.          is derived from the name of the logical
  673.          device this networkInterface represents for the
  674.          operating system, e.g. le0, COM1 */
  675.  MAY CONTAIN {
  676.   networkInterfaceAddress  :: caseIgnoreStringSyntax,
  677.    /* this should contain a protocol-independent
  678.          interface address, e.g. Ethernet board number */
  679.   connectedNetwork :: distinguishedNameSyntax,
  680.    /* pointer to object of network which this networkInterface is
  681.       connected to */
  682.   }
  683.  
  684.  
  685. 6.3 Logical Elements
  686.  
  687. An abstract view of a physical element is called image in this document.
  688. The  word  image  gets  appended  to the object type, leading to the new
  689. objects networkImage, nodeImage and networkInterfaceImage.  Images  will
  690. either  build  Directory trees of themselves or be stored as part of the
  691. physical network tree (see  section 5).
  692.  
  693. Image objects inherit properties of the ImageCommunicationObject class.
  694.  
  695. Each image object has specific attributes which vary  depending  on  the
  696. point  of  view  (IP, OSI, ...). Also, the user and provider of an image
  697. will view an object differently; further a user of an object may also be
  698. providing the services of the same object to another user.
  699.  
  700. Therefore, in the following a complete and general  list  of  attributes
  701. cannot be given.  We recommend to define subclasses of Image classes for
  702. each logical view. These subclasses inherit all attributes defined  with
  703. the object classes below and add more specific attributes.  Examples for
  704. an IP-view are given in [IP].
  705.  
  706.  
  707. 6.3 1 Network
  708.  
  709. There may be several network  images  for  one  and  the  same  physical
  710. network:  one for each protocol, application, etc.
  711.  
  712. networkImage OBJECT CLASS
  713.  SUBCLASS of ImageCommunicationObject
  714.  MAY CONTAIN {
  715.   externalGateway :: distinguishedNameSyntax,
  716.    /* points to one or more nodes that act
  717.       as gateway for the protocol application
  718.       this images referes to */
  719.  
  720.  
  721.  
  722. Expires: March 1, 1994                                       [Page 11]
  723.  
  724.  
  725.  
  726.  
  727.  
  728. Internet Draft                 OSI-DS 37                  September 1993
  729.  
  730.  
  731.   speed :: numericStringSyntax,
  732.    /* nominal bandwidth for the channel dedicated
  733.       to this protocol or application ,
  734.       e.g. 64 kbps */
  735.   traffic :: numericStringSyntax,
  736.    /* (average) use in percent of nominal bandwidth
  737.          [ this needs more specification later ] */
  738.   charge  :: numericStringSyntax
  739.    /* amount of money that has to be paid to
  740.          service provider for usage;
  741.          [ it is felt that this needs further definition:
  742.          e.g. monetary unit / time unit, monetary unit /
  743.       data unit ] */
  744.   }
  745.  
  746.  
  747. 6.3.2 Node
  748.  
  749. Name and functionality within the network might vary  for  a  node  from
  750. protocol  to  protocol  considered.  In  particular, a node might act as
  751. gateway for one protocol but not for the other. Routing policy is stored
  752. in the case of policy gateways.
  753.  
  754. nodeImage OBJECT CLASS
  755.  SUBCLASS of ImageCommunicationObject
  756.   /* no attributes common for all nodeImages have been
  757.      defined yet */
  758.  
  759.  
  760. 6.3.3 NetworkInterface
  761.  
  762. As   with   physical   nodes,    nodeImages    have    networkInterfaces
  763. (networkInterfaceImages)  which  describe  connectivity to other network
  764. elements. NetworkInterfaceImages are  only  given  if  the  protocol  is
  765. establishing connections via this networkInterface.
  766.  
  767. networkInterfaceImage OBJECT CLASS
  768.  SUBCLASS of ImageCommunicationObject
  769.  MAY CONTAIN {
  770.   networkInterfaceAddress :: caseIgnoreStringSyntax,
  771.    /* the networkInterface address in the image context,
  772.       e.g. IP number, NSAP */
  773.   connectedNetwork   :: distinguishedNameSyntax
  774.    /* pointer to networkImageObject that describes
  775.          the network this networkInterface is attached to in terms
  776.          of the protocol or application the image
  777.          indicates */
  778.   }
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788. Expires: March 1, 1994                                       [Page 12]
  789.  
  790.  
  791.  
  792.  
  793.  
  794. Internet Draft                 OSI-DS 37                  September 1993
  795.  
  796.  
  797. 7. Security Considerations
  798.  
  799. Security Considerations are not discussed in this draft.  However,  data
  800. access  control  will be taken care of by means of the Directory (namely
  801. X.509).
  802.  
  803.  
  804. 8. Authors' Addresses
  805.  
  806. Thomas Johannsen                      Glenn Mansfield
  807. Dresden University of Technology      AIC Systems Laboratories
  808. Institute of                          6-6-3 Minami Yoshinari
  809. Communication Technology              Aoba-ku, Sendai 989-32
  810. D-01062 Dresden                       Japan
  811. Germany                               Phone: +81-22-279-3310
  812.  
  813. EMail:                                glenn@aic.co.jp
  814. Thomas.Johannsen@ifn.et.tu-dresden.de
  815.  
  816.  
  817.                 Mark Knopper
  818.                 Merit Network, Inc.
  819.                 1071 Beal Avenue
  820.                 Ann Arbor, MI 48109
  821.  
  822.                 EMail: mak@merit.edu
  823.  
  824.  
  825. References
  826.  
  827. [X.500-88]  CCITT:
  828.             The Directory - Overview of Concepts, Models and Services;
  829.             Recommendations X.500 - X.521
  830.  
  831. [HK 91]     Hardcastle-Kille, S.:
  832.             X.500 and Domains;
  833.             RFC 1279, November 1991.
  834.  
  835. [IP]        Johannsen, Th., G. Mansfield, M. Kosters, S. Sataluri:
  836.             Representing IP information in the X.500 Directory;
  837.             Draft proposal OSI-DS-38, August 1993.
  838.  
  839. [SPP]       Johannsen, Th., G. Mansfield:
  840.             The Soft Pages Project;
  841.             Draft proposal OSI-DS-39, February 1993.
  842.  
  843. [OSI-DS-14] Weider, Ch., M. Knopper:
  844.             Interim Schema for Network Infrastructure Information
  845.             in X.500;
  846.             Internet Draft osi-ds-14, March 1991.
  847.  
  848. [OSI-DS-16] Weider, Ch., M. Knopper:
  849.             Schema for Network Information Center (NIC) Profiles
  850.             in X.500;
  851.  
  852.  
  853.  
  854. Expires: March 1, 1994                                       [Page 13]
  855.  
  856.  
  857.  
  858.  
  859.  
  860. Internet Draft                 OSI-DS 37                  September 1993
  861.  
  862.  
  863.             Internet Draft osi-ds-16-01, March 1992.
  864.  
  865. [OSI-DS-19] Weider, Ch., M. Knopper, R. Lang:
  866.             Interim Directory Structure for Schema for Network
  867.             Infrastructure Information;
  868.             Internet Draft osi-ds-19, April 1991.
  869.  
  870. [Knopper]   Knopper, M:
  871.             Representing Networking Infrastructure Information
  872.             in X.500;
  873.             OSI-DS WG document, July 1992.
  874.  
  875. [WHOIS]     Harrenstein, K., M.K. Stahl, E.J. Feinler:
  876.             NICNAME/WHOIS;
  877.             RFC 954, October 1985.
  878.  
  879. [DNS]       Mockapetris, P.V.:
  880.             Domain names - implementation and specification;
  881.             RFC 1035, November 1987.
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920. Expires: March 1, 1994                                       [Page 14]
  921.  
  922.  
  923.